Flash EPROM (erasable programmable read-only memory) devices have developed into a popular source of non-volatile, electrically erasable memory in a wide range of digital applications. Flash memory devices typically use a one-transistor memory cell which allows for high memory densities, high reliability, and low power consumption. These characteristics have made flash memory very popular for low power applications, such as battery-backed or embedded memory circuits. Common uses of non-volatile memory include portable computers, Personal Digital Assistance (PDA) devices, digital cameras, and cellular telephones. In these devices, both program code and system data, such as configuration parameters and other firmware, are often stored in flash memory because of the compact storage and relative ease of software upgradeability. The use of flash memory to store upgradeable data has necessitated the development of mechanisms to protect the data from unintended erasure or reprogramming.
With original flash memory devices, erasing stored code or data required erasing the entire device. Newer devices, however, are based on a block-erase architecture in which the flash memory is divided into blocks that are loosely analogous to the disk sectors recognized by disk operating systems. This block based architecture allows file systems to erase blocks of flash memory instead of the whole device. The block architecture also allows users to flexibly erase different portions of code or data in a flash device. For example, critical system code, such as boot code, can be stored in a lockable "boot block" of the device, while other blocks are allocated to other portions of code or data.
To ensure the integrity of block-based flash memory, block protection schemes are needed to protect stored data when the memory is modified through program or erase operations. Memory blocks must be protected against unintended writes when data is written to the device or when a new code segment is updated. Likewise, data blocks must be protected when other data blocks are modified or when code updates occur.
One present method of block protection for flash memory includes protecting a pre-determined number of blocks through a lock/unlock hardware pin. This requires the user to determine which blocks of memory are hardware protectable and reserve those blocks for critical data or program code. This approach is highly inflexible in that the user can only protect code or data in these pre-determined hardware protectable blocks.
A second present method of block protection for flash memory includes the use of a block locking configuration table that is stored in the flash memory device itself. Typically the configuration is stored in a flash mini-array that is separate from the main flash memory array. Each bit in the configuration table represents a block that can be either locked or unlocked. This approach, however, has several disadvantages. One disadvantage is the excessive latency incurred in locking or unlocking individual blocks of memory. For example, in a typical flash device, on the order of ten microseconds are required to program a lock bit and one second is required to erase a lock bit. In systems in which code is being executed on the order of thousands of megahertz, these long cycle times required to protect memory blocks can to protect memory blocks can create create periods of vulnerability in which data corruption may occur.
Another disadvantage to this method is that, because the table is implemented in a dedicated flash mini-array, in which individual bits represent the different lockable blocks, reprogramming a particular block typically requires erasing the entire set of bits in the table, instead of only the bit for that block. Thus, reconfiguring even a single block incurs the erase cycle times for each of the bits in the table and the associated vulnerability to data corruption of these bits during the relatively long erase times.
An additional disadvantage of the flash based configuration table is that it occupies valuable die space in the flash device and each bit in the table requires associated flash sense, and program and erase circuitry.
Therefore, present methods of block protecting flash memory present several significant disadvantages, including inflexibility of lock configuration, higher costs due to addition of a flash mini-array, and possible data corruption due to vulnerability resulting from long program and erase cycle times.